Skip to main content

Using Asynchronous Activities

Overview

Within the processes, Bizagi features the possibility to execute certain tasks asynchronously from the Work Portal.

This allows end users to finish up their tasks, regardless of what the next step of the process is, and have Bizagi process that next step as a background task (without user interaction).

In Bizagi, such tasks are known as asynchronous Activities; and through them, you may also configure an asynchronous communication with an external system.

To indicate in the process that certain task needs to be executed asynchronously, you will need to first make sure you use a BPMN-standard Service Task (task of the service or automatic type), and that you set it up with the property that sets it as asynchronous.

Asynchronous Overview

Why use asynchronous Activities?

Asynchronous Activities have been especially designed to provide a special treatment where there is the need to integrate with external applications.

Either by means of web services, or direct invocations done through custom components (i.e., Component library), a special treatment is required when connecting to external applications so that these aspects are considered:

  • Should the external application be offline (or temporarily off service), then Bizagi will queue up that execution and automatically retry it as an background task.
  • Should the execution be delayed, then a timeout will take place, leaving that processing as pending and to be automatically retried as a background task.

Asynchronous Information

  • Should the execution be delayed, you can best manage the transaction with Bizagi to avoid potential locks in the database.

Given the nature of an integration point in the process, which has a high possibility of presenting a significantly extended execution time (due to external variables such as: the connection's state, the external application's processing capacity to respond, etc.), it is a best practice and ideal for the overall performance that this transaction is handled apart from other simultaneous activities or pending transactions in the Work Portal fired by all end users.

Note:
Bizagi manages the access to data through its components (such as the Entity Manager), by implementing several measures to avoid locks and optimize persistence operations (i.e., writes to the database).

The above allows Bizagi to commit transactions in the database upon users completing Activities in the Process workflow, and have the Work Portal automatically load up and manage next tasks.

Since these transactions are intended to be committed in a fast way, it is best to use the asynchronous treatment for connections with other applications because usually in these scenarios, the time employed for their completion varies greatly (may increase an uncertain amount of time), and you do not have any control over this.

Asynchronous A2A communication

In addition to the above reasons, this type of task allows you to model in Bizagi an asynchronous communication approach with an external application, by relying also on a BPMN-standard intermediate Event.

In the figure below, notice that you may have Bizagi trigger processing at the external application through the Interface task, and receive an ACK (acknowledgment of receipt) right away from the external application.

The process moves on to a next task, but in the meantime, it also awaits for the completion of the intermediate Event below.

Good Practices

Once the external application finishes up its triggered processing, it can fire in return the Event in Bizagi, by making use of Bizagi's web services API (SOA layer).

Keep in mind that for this model, you would need to send through the initial Interface message all the relevant callback address and information for the external application to notify back to Bizagi (having the Event's id, and any additional metadata).

How do asynchronous Activities work?

Asynchronous Activities are a variant of the way in which a Service Task can execute (though, the preferred variant).

This feature works as described below:

  • When the process finds an asynchronous Activity, actions set at the On Enter timing of that activity (typically business rules) are immediately processed.
  • When the transaction associated with those actions at the On Enter timing ends, then the pending actions at the On Exit timing (business rules, web services, components, etc.) will be executed in a separate, new transaction.
  • At this point, the completion of that Activity will be represented as pending to the end users (or shown as "processing..." when using a Show feedback property).

This is different from activities not being asynchronous because in the default treatment, both On Enter and On Exit actions will roll back when an error is produced at the On Exit timing.

  • If the asynchronous Activity fails, then it will be handled in automatic retries by the Scheduler service (as a background task).
  • Once the execution is retried and successful, the Scheduler notifies the Work Portal that the next Activity is available (end users will see this Activity as available by looking at their inbox, or by means of an email notification if designed that way).

Modeling the Process

On the other hand, if the execution continuously fails until the predefined number of retries is exhausted, this activity will be shown under the asynchronous Activities console with a corresponding log (for an administrator to diagnose and review such repetitive errors' cause).

Even when within the process workflow, next steps are as well other asynchronous Activities (chained sequentially), then Bizagi will handle each asynchronous Activity in a separate transaction so that each will handle a rollback to that given point.

How to configure an asynchronous Activity?

Asynchronous Activities are defined when creating the Process model (in the first step of Process Wizard by using BPMN-standard Service Tasks).

From that point, you may configure each of the Service Tasks to work as asynchronous Activities.

To configure it, from step #1 of the process wizard in Bizagi Studio (Modeling the process) carry out the following:

  1. Right-click on a Service Task and choose the Properties option.

    Asynchronous Properties

  2. Locate the set of properties for asynchronous treatment under the Runtime tab.

    Asynchronous Information

  3. Enable the Is Asynchronous property.

Once enabled, enter the details for the asynchronous execution parameter which mainly consider how to handle errors that may occur during its execution.

Administration of asynchronous Activities and retries

Notice that a number of retries can be configured so that, should an asynchronous Activity fail, Bizagi can automatically retry it without user intervention.

The Activity will not be retried automatically when the number of retries is exhausted.

In these cases, the intervention of an administrator will be required, who will be able to use the asynchronous Activities console options in the Work Portal (to review and manually retry these exceptional cases).

To view more information about these Administration options, refer to Asynchronous Activities Administration.